this looks good to me, curious to hear your thoughts @jhamman since you are the mode architect

Would it be possible instead to provide a UserWarning and return a read-only copy of the store? I'm concerned about the downstream impacts of this change (e.g., see xarray failures reported in #3105 (comment)).

My thinking here with an error was to avoid situations where one opened an array with mode='r', but writing to it still worked. So although it has the potential to be disruptive, it's avoiding confusion with the API so I think worth it.

At a slightly higher level, I don't really understand why arrays can't have their own read/write permissions, but I missed that design decision.

My thinking here with an error was to avoid situations where one opened an array with mode='r', but writing to it still worked. So although it has the potential to be disruptive, it's avoiding confusion with the API so I think worth it.

I definitely agree with the premise of avoiding situations where one opened an array with mode='r' but writing still works.

I still question this solution because it will certainly be disruptive. The decision to defer read/write permissions to only the store level is an internal design detail that could be changed without any user facing disruptions, so IMO it'd be better to reconsider that decision before releasing a disruptive change.

IIUC since the array has a reference to the store used at creation rather than a copy, this check doesn't really suffice to solving the situation where one opened an array with mode="r" if the store mode were become mutable (xref #3105). While it seems likely that @d-v-b understands that consequence and is arguing against it, a separate array mode would protect against store changes badly influencing array behavior in a more robust way.